Of the many uses of the Internet, one of the more common ones is to access content on a remote server, such as a World Wide Web server. Typically, a person operates a client device to access content on a remote origin server over the Internet. The client may be, for example, a personal computer (PC) or a handheld device such as a personal digital assistant (PDA) or cellular telephone. A person using the client typically operates a browser to locate and select content stored on the origin server, such as a web page or a multimedia file. In response to this user input, the browser sends a request for the content over the Internet to the origin server on which the content resides. In response, the origin server returns a response containing the requested content to the client, which outputs the content in the appropriate manner (e.g., it displays the web page or plays the audio file). The request and response may be communicated using well-known protocols, such as transmission control protocol/Internet protocol (TCP/IP) and hypertext transfer protocol (HTTP).
For a variety of reasons, it may be desirable to place a device known as a proxy logically between the client and the origin server. For example, organizations often use a proxy to provide a barrier between clients on their local area networks (LANs) and external sites on the Internet by presenting only a single network address to the external sites for all clients. A proxy normally forwards requests it receives from clients to the applicable origin server and forwards responses it receives from origin servers to the appropriate client. A proxy may provide authentication, authorization and/or accounting (AAA) operations to allow the organization to control and monitor clients' access to content.
It is also common for a proxy to operate as a cache of content that resides on origin servers; such a device may be referred to as a “proxy cache”. An example of such a device is the NetCache product designed and manufactured by Network Appliance, Inc. of Sunnyvale, Calif. The main purpose of caching content is to reduce the latency associated with servicing content requests. By caching certain content locally, the proxy cache avoids the necessity of having to forward every content request over the network to the corresponding origin server and having to wait for a response. Instead, if the proxy cache receives a request for content which it has cached, it simply provides the requested content to the requesting client (subject to any required authentication and/or authorization) without involving the origin server.
Proxy caches may also be used to facilitate transformations of the requested content prior to returning the requested content to the requesting client. Examples of such transformations include translation of web pages retrieved from the origin server to different formats depending on the client device type (e.g., a PDA, a cellular telephone, etc.), translation of web pages to different human languages, insertion of advertisements into web pages, checking web pages for viruses, etc. For each type of transformation, a proxy cache may balance the distribution of content transformation tasks associated with numerous client requests between a collection of services running multiple instances of a designated content adaptation application.
Often, a group of servers is deployed to implement content adaptation, and each server may run one or more independent instances of a particular service. Because each service within the collection of services (also known as a service farm) is independent, it is possible that, at a given point of time, the services within the service farm may be running different versions of the application. Specifically, the existence of multiple versions within the service farm may be caused by administrative and management tasks which upgrade and downgrade services, add new services that run an application version other than that of the existing services, modify service configurations (e.g., an addition of virus signatures to a virus checking service), modify data used by a service (e.g., a content filtering application uses a database which is periodically refreshed by downloading it from a particular server), etc.
Content transformations performed by services running different versions of the same application may result in inconsistent semantics of a content adaptation process as a whole. For example, when services within a service farm execute different versions of the same application, they provide different transformation results of the same content to the clients, resulting in inconsistencies across clients. Further, a web page including multiple objects may itself appear inconsistent since its constituent objects may be transformed by different versions of a content adaptation application.
One known solution for the above problems involves taking the entire service farm offline or taking each service offline in sequence when performing administrative and management tasks causing version modifications. However, this approach decreases the availability of content adaptation services, which may not be acceptable if the services run a critical application such as virus checking. In addition, because these administrative and management tasks are typically time-consuming, the above approach may result in severe performance degradation. Further, the above approach requires manual intervention when taking services offline, which may not always be possible (e.g., in case of automated database downloads by content filtering services).
Another existing approach for solving the above problems involves implementing, on a service farm, a mechanism preventing different versions of a content adaptation application to be simultaneously active. However, this approach typically requires that services within the farm run cluster management protocols, thus incurring extra network overhead in the form of maintaining group membership information. As a farm scales, the network bandwidth overhead can be substantial. Furthermore, network conditions such as network partitioning can divide a farm into multiple independent islands in which services can run different application versions, thus making this solution futile.